Windows Deployment Services (x86) #2511
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Compatible with both x86 and x64 systems. Tidy up the module...
Also tidyup indents and use predefined UUID syntax.
|
Related to #1420 |
|
So, sometimes I get this: I think there are a couple over-eager rescues in here. Also, I often end up with a bunch of open connections. When the module ends, I'm still left with: Normally, hanging connections like this get handled with Here's a more normal run: and now I have another connection: Going to see what I can do to detangle this. |
|
It feels like when you open the DCERPC connection to WDS, if you never close it, that WDS server is out of the unattend.xml-serving business. |
|
This is on my Wink2k3 machine, btw. |
|
By the way, the + rescue isn't consistent. Here's a good run, after restarting WDS: |
|
So, it looks like for each arch, you need to set up the handle, get the file, and then tear down the handle. |
|
Sometimes, the returned data (dcerpc.last_response.stub_data) gets chopped off. Hmm. Here's an inspect: |
|
So, when it works, after this next commit, I often get this: However, I often get incompletes, and it looks like the socket read is cutting off between packets. Here comes a pull request; I'm thinking we need to be slower on the RPC read in order to actually pick up the data, then close out the connection. It feels like, on Win2k3, that we're running into a locking situation on the WDS server. |
|
See Meatballs1#28 |
|
Note that all of my problems may just boil down to my crummy 32-bit server. @Meatballs1 may have never seen these protocol snafus in 64-bit land, and this PR #2511 does indeed solve the fundamental cross-compat issues. If I don't get any feedback on this in the next hour or so, I'll land this, and we can tinker with Meatballs1#28 in the meantime. |
|
Regardless of Meatballs1#28, this PR and 50b1dd9 could be landed right now to just deal with the 32-bit RPC transfer syntax and avoid the NoMethodError on nil. |
|
So, I'm still racing DCERPC, looks like, but now my sessions are at least closing cleanly. I'll land this now to get around those problems. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@todb-r7
There's really no point supporting NDR64 syntax as x64 systems will talk NDR32 without issue. So dropped back to the default syntax and corrected the module. Also performed various tidyup tasks after ~12 months more MSF dev experience.
Should play nicely with 2k3 x86 -> 2k8 x64 and I assume 2k12...